Review

The architectural shift makes sense: client-side frame counting is a cleaner abstraction than wire-level control frames, and moving it to core means it works for any world that returns a ReadableStream from readFromStream, not just world-vercel. The reconnect math, frame-counting, and partial-frame discard are all correct.

But there are two significant concerns I think need addressing before merge.

1. Byte streams lose auto-reconnect entirely

The PR explicitly opts byte streams out of reconnect:

if (value.type === 'bytes') {
  // No auto-reconnect here: raw byte streams have no wire framing
  const readable = new WorkflowServerReadableStream(value.name, value.startIndex);
  // ...
} else {
  const readable = createReconnectingFramedStream(value.name, value.startIndex);
  // ...
}

The reason given is technically correct (no wire framing → no chunk boundary detection client-side), but this is a regression vs. the reverted #1790, which handled byte streams just fine because the server sent the resume hint via control frame.

The use cases that lose auto-reconnect:

• AI streaming responses (text/SSE) piped from getWritable()
• Any HTTP route doing return new Response(run.getReadable()) for raw bytes
• Any streaming workflow output that goes more than 2 minutes (the prior server-side timeout window) and uses byte type

The docs callout added by this PR points users to WorkflowChatTransport and supportsCancellation, but those address a different problem (cancellation, not reconnect). Pushing reconnect to the application layer — where every consumer has to reimplement it — is a step backward in usability.

Possible directions:

1. Frame byte streams on the writable side too (4 bytes per chunk overhead) so createReconnectingFramedStream works for them. The user-facing surface stays raw bytes; only the wire format changes.
2. Keep the control-frame approach for byte streams only as a hybrid — frame counting for non-byte streams, server-side hint for byte streams.
3. Document this as an explicit limitation and update the docs callout to specifically warn about byte streams losing reconnect, not just talk about supportsCancellation (separate issue).

(1) seems best to me — it removes the asymmetry entirely and keeps the cleaner architecture.

2. The "clean EOF means done" assumption needs verification

if (result.done || !result.value) {
  // Clean EOF — stream is truly complete...
  controller.close();
  return;
}

This assumes the workflow-server signals "done" and "timeout/aborted" differently at the network level — clean done = FIN, timeout = error/reset. The deleted control-frame logic disambiguated these because both manifested as clean closes from a TCP perspective; the magic-footer frame was the disambiguator.

Without the control frame, the new code can't tell them apart. If the workflow-server's 2-minute timeout sends a clean FIN (rather than a TCP reset or stream error), this PR will appear to "complete" any stream that hits 2 minutes.

Is that assumption verified against the actual server behavior? The new test simulates max-duration as controller.error(...), which is fine for the unit test, but I'd want to see either:

• An e2e test confirming a real long-lived stream against workflow-server triggers reconnect (not premature close)
• A statement in the PR description / commit explaining why the server-side timeout is now an error not a clean close (was the workflow-server changed? was the timeout removed?)

The supportsCancellation callout suggests the architecture has shifted such that streams now run for the full function maxDuration rather than the old 2-minute server timeout — but if so, that's a precondition for this PR and worth calling out explicitly.

Minor

See inline comments.

What looks good

• Frame-counting math is correct: currentStartIndex += consumedFrames resumes at the right place, partial-frame buffer is correctly discarded, the math is symmetric for non-zero initial startIndex.
• Negative startIndex correctly bypasses reconnect with a clear reason (can't compute absolute resume index without a tail-index lookup) — and there's a test for it.
• AbortController plumbing in world-vercel readFromStream is the right primitive. Cancel propagation through cancel(reason) { abortController.abort(reason) } correctly tears down the fetch.
• Test coverage for createReconnectingFramedStream is good — frames split across reads, partial frame at error, clean EOF, non-zero initial startIndex, negative startIndex bypass, cancel propagation. Six tests, all targeted.
• Two changesets correctly scoped: @workflow/core for the new wrapper, @workflow/world-vercel for the cancel propagation.

Approving — withdrawing my prior request-for-changes.

Context: my earlier blocker was that this PR opts byte streams out of auto-reconnect, which I called a regression vs. the now-reverted #1790. Since then we discussed it and settled on a different plan: this PR lands on stable as-is (object-stream reconnect only), and byte-stream support gets added on main/v5 via wire-level framing in a follow-up. The framing work is now in PRs #1854 (workflowCoreVersion on HealthCheckResult) and #1853 (the framing itself), which together let createReconnectingFramedStream be applied uniformly to byte streams on main once they land.

So for stable, this PR is the right scope:

• Object-stream reconnect via createReconnectingFramedStream is correct.
• Byte streams legitimately can't be auto-reconnected with the legacy unframed wire format that stable ships, so opting them out is the right call there.
• Frame-counting math, AbortController plumbing, world-vercel simplification all look good.

The earlier non-blocking concerns I raised still apply — would be nice to address them but I'm not gating on them:

1. The "clean EOF means done" assumption. Worth a sentence in the commit/PR description confirming whether workflow-server's stream timeout now manifests as a network error rather than a clean FIN, since the deleted control-frame logic was specifically there to disambiguate them.
2. FRAMED_STREAM_MAX_RECONNECTS = 10 is tighter than the deleted MAX_RECONNECTS = 50. Probably fine, but worth a sanity check against the longest realistic Pro/Enterprise maxDuration.
3. Cancel race during reconnect — pre-existing, not a regression here.

AI review: blocking issues found

Approve — with one hard pre-merge gate (the URL override) and two non-blocking design notes

I built @workflow/core + @workflow/world-vercel from this branch and ran the new suites locally: all 10 reconnecting-framed-stream tests and all 20 streamer tests pass.

The design is right

Moving reconnect from the adapter's wire-sniffing control-frame approach (#1790, reverted here) up to the framing layer is the correct factoring. The framing layer is the one place that already knows chunk boundaries, so "count completed frames, resume at startIndex + consumed" needs no wire protocol additions at all — and it works identically for any World adapter, not just world-vercel.

Specifics I verified:

• Partial-frame discard on reconnect is correct: buffered mid-frame bytes are dropped, currentStartIndex += consumedFrames, and the server resends the in-flight chunk in full. The test at line 140 simulates exactly the production scenario (3 bytes of a frame, then a max-duration abort) and asserts the resume index.
• The two-tier budget is well-reasoned. Consecutive cap (50) resets on forward progress, so a long-lived stream that reconnects hundreds of times while still delivering is never falsely killed — tested with FRAMED_STREAM_MAX_RECONNECTS + 5 productive reconnects. The absolute backstop (1000) covers the pathological case where a backend ignores startIndex and reports false progress forever — also tested. Both constants exported and documented with the reasoning.
• Clean EOF = completion, error = reconnect is the right contract, and negative startIndex (last-N) correctly opts out since an absolute resume position can't be computed.
• Frames pass through with headers intact to the downstream deserializer, which already expects the framed layout — the wrapper only counts, it doesn't re-frame. Nice and minimal.
• The byte-stream opt-out is correctly scoped (raw streams have no framing to count) and the doc callouts about supportsCancellation for long-lived stream routes are a genuinely useful addition independent of this change.

Hard gate before merge

WORKFLOW_SERVER_URL_OVERRIDE is pointed at a preview deployment. The in-code comment documents this as temporary and correctly predicts the red CI (the override lint guard + the 4 utils.test.ts override-precedence cases — I checked the failing unit job and those 4 are precisely the failures). This must go back to '' before merge, and CI needs one green re-run after the reset — the current Tests run is also three weeks old (May 29) relative to the branch head, and the MongoDB/Redis community-world results from that run are stale enough that I wouldn't sign off on them either way without a fresh run.

Non-blocking notes

1. A reconnect-time connection failure is fatal rather than budgeted. The retry budget only covers reader.read() errors. If reconnect() → connect() itself throws (the reopen fetch fails transiently — plausible during exactly the kind of server blip that triggers reconnect in the first place), the catch in pull errors the stream immediately with budget remaining. Folding connect failures into the same budgeted loop (count it, retry) would make the wrapper robust against the scenario it exists for. Fine as a follow-up.

2. The streamer's cancel-propagation wrapper trades away backpressure. The eager pump() loop in readFromStream reads upstream as fast as the network delivers and enqueues without consulting desiredSize, so a slow consumer now buffers the stream in the controller queue instead of letting the socket backpressure naturally (the old code returned response.body directly, which is pull-driven). A pull-based wrapper would keep the AbortController plumbing and preserve backpressure. For typical workflow stream sizes this is unlikely to matter, but it's an unnecessary semantic change for what is otherwise just abort plumbing.

3. Changeset bump types (patch for both packages on the GA channel) are defensible since this fixes silent truncation, even though it adds new behavior.

Once the override is reset and CI is green on a current run, this is good to land. The cross-PR sequencing in the description (this merging and releasing before the coordinated server-side behavior change takes effect) is the right order — until the server change ships, this code path simply never triggers, which makes it safe to release ahead.